Until recently, wireless mobile terminals have been used basically for making voice calls. Standardised and well-established communication technologies and protocols are then utilised to communicate voice between fixed and/or mobile terminals using circuit-switched communication channels.
However, a multitude of new telephony services involving “multimedia” are now rapidly being developed, enabled by the introduction of new technologies allowing for notably higher transmission rates and increased network capacity. For example, GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) technologies are currently emerging for enabling wireless telephony services requiring a wide range of transmission rates and different protocols and media formats.
The trend today is also a move towards packet-switched networks and technologies providing more capacity and flexibility as compared to the traditional circuit-switched networks. Further, new sophisticated mobile terminals are also emerging on the market, equipped with functionality to handle the new services, including high resolution colour displays and various codecs (coders/decoders) e.g. for visual information.
Multimedia services typically involve transmission of data representing text, documents, images, audio files and video files in a multitude of formats and combinations, and according to various different protocols. The term “multimedia” will be used in this description as generally referring to telephony services involving the transfer of any choice of media, typically with visual content, apart from ordinary voice, over a packet-switched network.
A prevailing goal or ambition in the field of telecommunication is to converge all services on to a single transport mechanism—the packet based Internet Protocol (IP), regardless of the type of access networks and technologies involved. A network architecture called “IP Multimedia Subsystem” (IMS) has therefore been developed by the 3rd Generation Partnership Project (3GPP) as an open standard, to give operators of access networks the ability to offer multimedia services in the packet domain. IMS is a platform for enabling services based on IP transport, involving the communication of multimedia content from one terminal to another over an IP network. IMS is more or less independent of the access technology used, and is basically not restricted to any limited set of specific services.
When using multimedia services, the prerequisites for a specific session will vary depending on the invoked service and the capabilities of the calling and called terminals, respectively, as well as on other factors. During a session, certain session parameters defining the rules of communication must be used by both the calling and called terminals in order to communicate the desired information. Such session parameters are related to codecs and storage means available in each terminal, as well as applications and signalling protocols.
Since many different types of terminals are available on the consumer market, two terminals about to communicate multimedia will most likely have different capabilities in some respect, and each terminal has typically no knowledge of the capabilities of the other. In order to establish an IP multimedia session, session parameters must therefore first be selected and established in a session set-up procedure, which is a kind of negotiation between the two terminals.
Thus, the terminals must exchange information regarding their specific capabilities and preferences, in order to agree on which session parameters to use during a forthcoming IP multimedia session, hereafter referred to as “capability exchange” for short. A specification for session set-up has been defined called “SIP” (Session Initiation Protocol, according to the standard IETF RFC 3261 et al). SIP is an application-layer control (signalling) protocol for creating, modifying and terminating sessions over a packet-switched network. The SIP standard is used by the above-mentioned IMS system to establish and control IP multimedia communications.
In the SIP protocol, a method called “INVITE” is defined when terminals about to communicate multimedia basically exchange their capabilities during the multimedia session set-up procedure. In this method, a calling terminal sends a session invitation message called “SIP INVITE” to a called terminal including its own capabilities, which then responds by sending over its capabilities to the calling terminal. In this way, both terminals will become aware of each other's capabilities, and can determine accordingly which applications and codecs that can be used in the forthcoming session.
Another method called “OPTIONS” is also specified in the SIP protocol allowing a terminal to query another terminal as to its capabilities regarding codecs and supported applications, without the user actually “calling” the other party. However, the user must of course first enter the telephone number of the other terminal. According to this method, the terminal then sends a capability query called “SIP OPTIONS” to the other terminal, preferably including its own capabilities, which responds by sending over its capabilities to the querying terminal. A “SIP OPTIONS update” message can also be sent if the capabilities are changed at a later stage.
The OPTIONS method can also be used during an ongoing voice call for enriching the call with multimedia communication. By way of example, a user may wish to send an image, a document, a video clip or audio clip, to the other user during an ongoing voice call, in order to discuss it at the same time. After exchanging their capabilities, the terminals may further indicate the optional multimedia available to its users, e.g. by displaying available services and/or applications as icons or the like on a terminal screen. A user can then easily select which type of service and media to use in a forthcoming session with the other party.
When the user presses a key or the equivalent on his/her terminal for submitting some selected content, the terminal first sends a session invitation message, inviting the other terminal to execute an IP multimedia session involving the transfer of the selected content, before submitting the actual content. The session invitation contains a description of the selected content/media, typically including information on the activated application as well as the coded format (e.g. jpeg, gif or 3gp) and data size (e.g. 50 Kbytes) of the selected content, thereby indicating what codec, application and storage capacity are required to receive the content. If the SIP standard is used in this procedure, the session invitation is the above-mentioned SIP INVITE message. Thus, the session invitation effectively queries the terminal if it is capable of receiving the selected content.
In PCT/SE03/01901, a solution is disclosed where the capability exchange procedure can be bypassed by storing (or “caching”) in each terminal the capabilities of the other terminal after a first multimedia session. When a second session is to be conducted between the same two terminals at a later occasion, the stored capabilities can be retrieved and used, merely by recognising the opposite terminal, in order to save time and signalling.
Hence, the terminal of a calling user can normally use any of the above-described methods to determine the capabilities of the terminal of a called user, in order to execute a multimedia session between the two terminals. However, the called user may have activated a call-forwarding service, meaning that any calls directed to a called primary communication unit are routed to a secondary communication unit instead, as selected by the called user. The re-routing of circuit-switched calls upon call-forwarding is generally handled by a service node or “core” in the home network of the called unit, which is a well-known procedure and therefore not necessary to described here further.
In different implementations of the call-forwarding service, the secondary communication unit may be a voice mail apparatus in which a spoken message or the like from the first user can be recorded and stored for later retrieval, or another terminal at which the called user, or another appointed person, can be reached. Calls may be forwarded in this way e.g. upon busy, no reply or immediate condition. Moreover, a call filtering function may be used where some specific callers will be forwarded and others will not. For example, all internal calls to a terminal within a private enterprise network may be directly connected, whereas all external calls to that terminal may be forwarded to a secretary's telephone or a voice mail apparatus.
A user calling another user by dialling the telephone number of a primary communication unit may wish to convey some multimedia content during the call to the called user, such as an image or a video or audio clip, even if the call has been forwarded to a secondary communication unit, such as another terminal or a voice mail apparatus.
However, it is currently not possible to send multimedia content to the secondary communication unit after calling the number of the primary communication unit, since there is no mechanism available to execute the above-described necessary capability exchange with a forwarded-to secondary communication unit. Any messages in current capability exchange procedures for multimedia, such as the above-mentioned SIP OPTIONS and SIP INVITE messages, are exclusively directed to the called telephone number, i.e. the number of the primary communication unit. Therefore, no capabilities can be exchanged with the secondary communication unit. The calling terminal (and its user) may not even be aware that the call has been forwarded.
Thus, when a call-forwarding service has been activated, the desired content cannot be conveyed to the secondary communication unit unless the calling user can make a new call directly thereto. This is a serious drawback, not least because the calling user is normally not aware of the fact that the call has been forwarded to another terminal than the one called. Moreover, it is typically not possible to call a voice mail apparatus directly.
These shortcomings will of course be perceived as a problem by terminal users not being able to convey IP multimedia content subject to call-forwarding, as well as by the network operators concerned being deprived of potential revenue from multimedia traffic. Hence, it is desirable to overcome the problem of conveying multimedia content during an ongoing call to a user currently utilising a call-forwarding service. It is also desirable to determine which multimedia options are available in communication with a terminal or voice mail apparatus to which calls are forwarded.